home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 319 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.3 KB  |  92 lines
  1. Newsgroups: comp.arch,comp.lang.c
  2. Path: uu4news.netcom.com!calcite!vjs
  3. From: vjs@calcite.rhyolite.com (Vernon Schryver)
  4. Subject: Re: Did Microsoft decree a byte order?
  5. Keywords: byte
  6. Message-ID: <DKMx16.E2M@calcite.rhyolite.com>
  7. Organization: Rhyolite Software
  8. Date: Thu, 4 Jan 1996 02:17:29 GMT
  9. References: <4c80dp$9du@hobbes.sco.COM> <DKIp84.9Az@calcite.rhyolite.com> <jgkDKMn2x.2KA@netcom.com>
  10.  
  11. In article <jgkDKMn2x.2KA@netcom.com> Joe Keane <jgk@netcom.com> writes:
  12. >In article <DKIp84.9Az@calcite.rhyolite.com>
  13. >Vernon Schryver <vjs@calcite.rhyolite.com> writes:
  14. >>Fooey.  Does SCO support more than one byte order in binary releases?
  15. >>Name an applications that uses XDR or ANS.1 for its disk data.  How many
  16. >>applications can you name that keep non-trivial amounts of data in ASCII
  17. >>to avoid byte order problems?  It is possible to write your applications
  18. >>so that their disk data is host byte-order independent.  It is almost
  19. >>never done because its costs in code size, execution time, development
  20. >>time, and long term bug fixing are each, seperately, intolerably high.
  21. >
  22. >Sorry, but this is baloney.  The real reasons are ignorance and laziness.
  23. >The other reasons are good excuses but they don't hold up under scrutiny.
  24. >
  25. >At some point, or maybe not, the light goes on in a programmer's head, that
  26. >read and write operate on *bytes* and maybe you should use them that way.
  27.  
  28. I think that is wrong.  
  29.  
  30. >Blasting structures directly to disk or the network is just bad practice.
  31. >
  32. >Important files and network data should have a real, well-defined format;
  33. >they shouldn't just be a core dump of whatever was in memory at the time.
  34. >Saying `but it works on my machine' isn't a sign of a competent programmer.
  35. >
  36. >Byte order is hardly the only problem; there are also differing type sizes
  37. >and structure padding.  Even on the same machine, these change when you use
  38. >a different compiler or compiler options.
  39.  
  40. I agree with practically all of that.
  41.  
  42. >                                           Code that depends on such things
  43. >will cause incompatibility again and again, but people will not learn.
  44. >
  45. >C++ objects add even more problems.  Besides the problems above, there are
  46. >virtual table pointers and virtual base pointers, which clearly can't work,
  47. >plus you don't even know what order the attributes will be stored in.
  48. >
  49. >What if GIF files didn't work between machines?  Or what about tar files?
  50. >What if you compress a file and can't uncompress it on a different machine?
  51. >People would say that someone is an incompetent bozo, and they'd be right.
  52.  
  53. No, that is wrong.
  54.  
  55. Contemplate the byte-order dependencies in the tar.  There are programs
  56. that can read and write all of the common cpio and tar formats, and
  57. these programs can be compiled to run on either big or little endian
  58. machines.  Nevertheless, neither tar nor cpio use XDR or ANS.1.  Also
  59. consider the fact that the LZW encoding used in GIF files is big-endian.
  60.  
  61. Backups are almost as good case study as network data of why people
  62. with clues rarely use byte-order independent formats.  You do not
  63. fondle the data so that it is self-describing and independent of (what
  64. you naively imagine are) all possible variations.  Instead, you pick
  65. a reasonable format, paying attention to alignment, packing, and so
  66. forth for a variety of machines, compilers, etc. covering your target.
  67. Then you add a version number to the structure and cast it in stone.
  68.  
  69. Yes, some rare times you do use XDR and ANS.1, when the balance between
  70. (supposedly) universal decoding and speed favors the former, as in
  71. the NFS control information (which uses XDR).  Notice that the main
  72. bits carried by NFS, the file data, are byte-order dependent.
  73. Yes, you often use ASCII, but only for trivial amounts of data
  74. or when speed is irrelevant, as in toys or log files.
  75.  
  76.  
  77. >Performance is a fine excuse but, take it from me, it's just an excuse.
  78.  
  79. Have you ever looked at code where speed matters?  For example, consider
  80. the fact that in RPC protocols, the performance bottleneck is generally
  81. in marshalling and unmarshalling.  NDL compilers and rpcgen continues
  82. to be a topic for papers, just because of the costs of universal
  83. encodings.
  84.  
  85. The original subject was whether it is reasonable for NT to pick only
  86. little-endian.  My quoted words above are a rant against ASCII, ANS.1,
  87. or XDR for byte-order independence.  Are you really arguing against
  88. either of those positions?
  89.  
  90.  
  91. Vernon Schryver    vjs@rhyolite.com
  92.